Systems and methods for bridging coverage

ABSTRACT

Systems and methods to provide bridging insurance coverage are described. The apparatus may comprise, a receiver module to receive a request for a financial service from a requestor and an underwriter module to underwrite a bridging financial service. The method may comprise, receiving from a requestor a request for a financial service, underwriting a bridge financial service at the time of the request, and initiating the external processes required for the approval of a final insurance policy. The method may additionally include, completing the external processes, underwriting a final financial service based on the external processes and terminating the bridge financial service.

RELATED APPLICATIONS

This disclosure is related to U.S. patent application Ser. No.11/321,220, titled “SYSTEMS AND METHODS FOR BRIDGING COVERAGE,” and U.S.patent application Ser. No. 11/321,480, titled “SYSTEMS AND METHODS FORBRIDGING COVERAGE,” both filed on Dec. 29, 2005.

TECHNICAL FIELD

This application relates to systems and methods for account processingof a service customer and more particularly to systems and methods ofproviding bridging insurance coverage for a customer.

BACKGROUND

Life insurance is one component of financial stability. Life insuranceprovides stability for those that are left behind. Planning ahead andsecuring life insurance ensures that they are taken care of. This isjust one aspect of the many financial services that a person needs forfinancial stability.

Life insurance provides a financial benefit to a beneficiary if theinsured dies. This benefit is one way the insured can be certain thatthe beneficiary is financially stable even when they are gone. The lifeinsurance policy is a contract between the insurance company issuing thepolicy and the insured. In return for the payment of regular premiums tothe insurance company, the beneficiary of the policy gets a payment whenthe insured dies. The insurance company is motivated by financialconcerns to reach a balance between the amount of money brought in withpremiums across all life insurance policies and the money paid out tobeneficiaries. The insurance company collects information when a newcustomer requests a life insurance policy. This information enables theinsurance company to properly set the premium payment by assessing therisk of the customer. If, for instance, the potential customer isemployed in a high-risk occupation such as race-car driver, the risk tothe insurance company insuring them is higher, so, the premium paymentswill be higher. However, a higher premium payment may mean that thecustomer does not accept the policy and the company loses that potentialbusiness. The company needs to make this balance between lower premiumsthat attract more new customers, but potentially higher risk and higherpremiums that lower the financial risk to the company, but fewercustomers.

In addition to life insurance, there are many other aspects of financialstability, such as banking accounts, mortgages, retirement accounts, andbrokerage accounts.

SUMMARY

In an embodiment, an apparatus to provide bridging coverage comprises areceiver module to receive a request for a financial service from arequestor and an underwriter module to underwrite a bridging financialservice. In an embodiment, a method to provide a bridging coverage to acustomer includes receiving from a requestor a request for a financialservice, underwriting a bridge financial service at the time of therequest, and initiating the external processes required for the approvalof a final insurance policy. In a further embodiment, the methodadditionally includes completing the external processes, underwriting afinal financial service based on the external processes and terminatingthe bridge financial service.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments are illustrated by way of example and not limitation in thefigures of the accompanying drawings, in which like references indicatesimilar elements and in which:

FIG. 1 is a high level block diagram of a system for processing of acustomer for financial services, in accordance with an exampleembodiment;

FIG. 2 is a high level block diagram of customer processing, inaccordance with an example embodiment;

FIG. 3 is a more detailed architecture of a system for customerprocessing, in accordance with an example embodiment;

FIG. 4 shows a flow diagram of a method of customer processing; inaccordance with an example embodiment;

FIG. 5 shows a flow diagram of a more detailed method of processing acustomer for insurance coverage, in accordance with an exampleembodiment;

FIG. 6 shows a flow diagram of a method of processing a customer forfinancial services in a system, in accordance with an exampleembodiment; and

FIG. 7 is a block diagram of a machine including instructions to performany one or more of the methodologies described herein.

DETAILED DESCRIPTION

In the following detailed description of example embodiments, referenceis made to the accompanying drawings, which form a part hereof, and inwhich is shown, by way of illustration, specific embodiments in whichthe example method, apparatus, and system may be practiced. It is to beunderstood that other embodiments may be utilized and structural changesmay be made without departing from the scope of this description.

FIG. 1 is a high level block diagram of a system 100 for the processingof a customer for financial services, in accordance with an exampleembodiment. Financial services include, without limitation: lifeinsurance, secured loans, mortgages, brokerage accounts, or any accountwhere the customer is required to provide information and receiveapproval before the financial services are provided. In one embodiment,the system 100 comprises a services company 104 providing a financialservice 106. The service company provides the financial service to arequestor 102, in one example. The requestor 102 includes any individualrequiring some financial service 106 from the services company 104. Theservices company 104 may include, without limitation, an insurancecompany, a banking institution, a lending institution, a brokerageservice, and the like. In one embodiment, the financial service 106 is alife insurance policy underwritten by an insurance company which pays apre-set benefit to a beneficiary provided one or more premium paymentsare paid to the insurance company.

In an embodiment, the services company 104 requires information prior tothe issuance or setting up of the financial service 106. The servicescompany 104 acquires this information at least in part through one ormore external processes 108. However, the one or more external processes108 create a delay between when the requestor 102 requests the financialservice 106 and when the services company 104 issues or sets it up.These external processes 108 may include without limitation, backgroundinvestigation, medical examination, blood or urine analysis, titlecheck, credit check, and the like.

Using life insurance as the financial service, an illustrative exampleregarding FIG. 1 can be described. The insurance company agrees toprovide a life insurance policy to the requestor 102, so long aspremiums are paid in a timely manner. The premiums are the requestor'sportion of the contract as discussed above. Premiums are set by theinsurance company based on the particular situation of the requestor 102and represent the insurance company's revenue from the life insurancepolicy. By properly setting premiums across all insured persons, theinsurance company is able return a profit. If the premiums are set toolow, the insurance company could lose money as the policies are paidout. If the premiums are set too high, the insurance company could losea potential customer to another company willing to underwrite the policyfor a lower premium. In another context, the premium is the company'smechanism to manage risk over the aggregate of all insured parties.

In the context of a life insurance policy, the particulars include,without limitation, age, occupation, medical condition, and amount ofcoverage. Based on this information, the insurance company sets apremium for the policy. Unfortunately, the acquisition and verificationof this information takes time. For example, a determination of medicalsoundness may require a blood or urine sample, or physical examination.Additionally, the requestor 102 may need to complete one or more forms.Alternatively, for other financial services, additional information maybe required, such as, title searches for loans secured by a property, acredit rating for an unsecured loan, or a credit check. Mention ofspecific examples are intended to be illustrative only and are not meantto be limiting in any manner. Any information that a company may requirein order to provide a financial service to a customer is considered tobe within the scope of the present discussion.

The delay between requesting insurance and the issuance of the finalinsurance policy creates a situation where the requestor 102 is notcovered by insurance despite their desire to be covered by someinsurance policy. The requestor 102 has no protection during thisperiod. Additionally, during this period the insurance company can losethe opportunity to sell the policy because of the delay. Furthermore,the requestor 102 may forget, lose the paperwork, become disinterested,or contact another insurance company.

In one embodiment, the services company 104 provides the financialservice 106 requested in a temporary manner to the requestor 102 whilethe one or more external processes 108 are completed. This temporaryservice provides the requestor 102 with the guarantee or piece of mindthey do not have while waiting for completion of various externalprocesses 108. In one embodiment, the temporary coverage is called abridging service. In an alternate embodiment, the temporary coverage iscalled an Instant Bind Service, such as an Instant Bind Life InsurancePolicy of United Serviceman's Automobile Association. But, thistemporary service creates an additional risk to the services company104, a risk that can be minimized using a variety of apparatus andsystems as described herein. Discussion regarding increasing the pieceof mind of the requestor 102 during the delay while one or more externalprocesses are completed is discussed below.

FIG. 2 is a high level block diagram of customer processing, inaccordance with an example embodiment. In an embodiment, a processingsystem 200 receives a request for insurance coverage 202 as an input andgenerates a bridging insurance policy 204. The processing system 200includes a receiver module 206 and an underwriter module 208, in anembodiment.

In an embodiment, the receiver module 206 is configured to receive arequest 202 for insurance coverage from a requestor 102. In anembodiment, the request 202 may be received over a Public SwitchedTelephone Network (PSTN). In an alternate embodiment, a form is manuallycompleted and sent via mail to the insurance company. In either of thesetwo cases, an agent at the insurance company may, in one example, enterthis information into a computerized system, such that the receivermodule 206 receives the required information directly from the agent andindirectly from the requestor 102. In another example, the request 202may be received over a computer network through any suitable means, suchas a web-enabled form. The request 202 may contain just a simple querywhereby the requestor 102 shows interest in the possibility of obtainingan insurance policy, or may contain all the information required fromthe requestor 102 to have their application begin to be processed forthe issuance of an insurance policy. In the example where the simplequery was sent, the receiving module may further query the requestor 102for more information sufficient to complete the application.

In an embodiment, the underwriter module 208 is configured toimmediately issue a bridging insurance policy 204. As discussed above,the time delay from initial request for an insurance policy to finalissuance creates a period where the requestor 102 is uncovered. Abridging insurance policy 204 as used here is meant to denote any policywritten immediately upon request for insurance. The bridging insurancepolicy 204 may not be a final insurance policy as discussed above withrespect to FIG. 1. The bridging insurance policy 204, in the context ofthe present discussion, is a time limited insurance policy that maycover the requestor 102 during the time it will take to complete the oneor more external processes 108 that the company needs to complete tomake a final determination regarding a final insurance policy. In anembodiment, the bridging insurance policy 204 may also be limited as tothe benefits it provides the requestor 102 in addition to the termlength.

The bridging insurance policy 204 may terminate when the final policy isissued or it can be converted into the final policy when such policy isapproved. It may or may not provide double coverage if it overlaps thefinal policy. The bridging insurance policy 204 may differ from thefinal policy in that it is underwritten when the initial request isprocessed. The bridging insurance policy provides coverage to therequestor 102 in the event of their death. Should the requestor 102 diewhile covered by the bridging insurance policy 204, the coverage amountmay be paid out to their beneficiary. Additionally, the bridginginsurance policy 204 may have an expiration date associated with it. Forinstance, the insurance company may decide that 90 days is a normalperiod of time to complete all the needed information. In that example,the bridging insurance policy 204 could be set to expire after 90 days.This ensures that the risk of writing the bridging insurance policy 204is lessened and provides an incentive to the requestor 102 to assist inthe timely submission of the needed information needed.

In one embodiment, the underwriter module 208 is operatively coupled tothe receiver module 206 such that information received in the request202 or in response to further queries is passed to the underwritingmodule 208. In another embodiment, the underwriter module 208 isconfigured to determine if the requestor 102 is eligible for a bridginginsurance policy 204 and only issues the bridging insurance policy 204if they are eligible.

FIG. 3 shows a more detailed architecture of an apparatus for customerprocessing, in accordance with an example embodiment. The apparatusdepicted in FIG. 3 is similar to that depicted in FIG. 2 with theaddition of a manager module 310 and an insurer module 312.

In an embodiment, the manager module 310 is configured to manageexternal processes 108 required to complete the final approval of apolicy or service. As discussed above, in order to issue a finalinsurance policy, several processes external to the insurance companyare performed prior to the issue. In the context of the presentdiscussion, external processes 108 may be any steps that are notperformed directly by the insurance company, such as a medicalexamination, form completion and the like. In the context of otherfinancial services, such external processes 108 may include, withoutlimitation, a credit report, property appraisal, backgroundinvestigation, or title check. Each of these requires an initial requestby the company and a subsequent reply to the request. The reply containsthe information requested. The manager module 310 is configured to senda request and to receive a reply to that request. In one embodiment, therequests may be sent electronically over any suitable network and thereply is received in a like manner. In another embodiment, an agent isprompted by the manager module 310 to request the information needed.Additionally, in that example, the agent is further prompted to enterthat information into the manager module 310 when the reply is received.In such an example, the prompting may be made by any suitable means suchas e-mail, automated telephone message, or an electronic task in a taskmanager software application.

In one embodiment, the receiver module 206, the underwriter module 208,the manager module 310, and the insurer module 312 are operably coupledand provide a comprehensive system by which a requestor 102 can requesta financial service, receive an instant bridging service, and beapproved for the financial service after the external processes 108 arecomplete. In the context of a life insurance policy and using theapparatus described here with respect to FIG. 2, such a system may beconfigured in the following manner. The receiver module 206 isconfigured to receive a request for a life insurance policy. The requestcontains information sufficient for the underwriter module 208 todetermine if the requestor 102 is eligible for a bridging insurancepolicy 204. The underwriter module 208 is configured to issue a bridginginsurance policy 204 for some amount. In addition to providing theinformation in the request to the underwriter module 208, the receivermodule 206 is configured to send that information to the manager module310. The manager module 310 is configured to initiate the externalprocesses 108 required by the insurer module 312. The insurer module 312is configured to receive the information obtained by the externalprocesses 108 and the initial request and make a determination to issuea final insurance policy. Following issuance of the final insurancepolicy, the bridging insurance policy 204 can be terminated, or in someexamples, converted into the final insurance policy. If the insurermodule 312 determines not to issue a final insurance policy or if theexternal processes 108 are unable to be completed within some specifiedtime period, the bridging insurance policy 204 is terminated.

FIG. 4 shows a flow diagram of a method of customer processing, inaccordance with an example embodiment. The method depicted in FIG. 4 maybe carried out in the system discussed above with respect to FIG. 1, inone example.

At block 405, a request for an insurance policy is received from apotential customer. At block 410, a bridging insurance policy is issued.In one embodiment, the bridging insurance policy is issued at the timethe full request is received. In one example, the request containsinformation sufficient to issue the bridging insurance policy. Inanother example, the request does not contain sufficient information. Insuch a situation, the potential customer can be queried for furtherinformation. In both examples, the bridging insurance policy can beissued at the time of the request, such that the potential customer isinstantly covered by a policy. At block 415, operations to determine ifa final insurance policy will be issued are initiated. As discussedabove, those operations could cause a large delay in time. With abridging insurance policy in place, the potential customer has aguarantee and the piece of mind that they are covered.

FIG. 5 shows a flow diagram of a more detailed method of processing acustomer for insurance coverage, in accordance with an exampleembodiment. The method depicted in FIG. 5 may be carried out in thesystem discussed above with respect to FIG. 1, in one example. Theoperations described in FIG. 5 begin similarly to those described abovewith respect to FIG. 4 with a request for an insurance policy receivedat block 405. In the operations described here with respect to FIG. 5,the end result is that a final insurance policy is issued.

At block 520, a determination is made regarding the requestor's 102eligibility for a bridging insurance policy. Eligibility may be based onany number of factors including, but not limited to, initial riskrating, requestor's 102 previous relationship with the company, amountof coverage requested, type of coverage requested, other servicesprovided to the requestor 102, and the like. If the requestor 102 iseligible for a bridging insurance policy, it will be offered to them. Ifthe requestor 102 is not eligible for a bridging insurance policy, theoperations required to issue a final insurance policy will be initiatedat block 525.

At block 530, the requestor 102 either accepts or declines the bridginginsurance policy. If the requestor 102 declines, the operations at block525 will be initiated. If the requestor 102 accepts, a bridginginsurance policy will be issued for a coverage amount at block 532. Inone example, the coverage amount is equal to the coverage amountrequested initially at block 405. In another example, the coverageamount for a bridging insurance policy has a maximum amount, such as$500,000. In such a situation, if the coverage amount requested at block405 exceeds $500,000, the bridging insurance policy will only be writtenfor $500,000. Alternatively, a coverage amount requested at block 405 inexcess of some pre-set amount will cause the requestor 102 to beineligible for a bridging insurance policy at block 520.

If the requestor 102 accepts the bridging insurance policy at block 530,the process to issue a final insurance policy is initiated at block 535.The processes initiated at block 535 are similar to those at block 525and may include one or more external processes 108 as discussed above.For example, a medical examination may be required prior to the issuanceof the final insurance policy at block 540. Additionally, the issuanceof the bridging insurance policy at block 532 may require furtheroperations to ensure that the bridging insurance policy is temporary innature. Based on the information obtained in the one or more externalprocesses 108 and the initial request, a determination to issue or notissue a final insurance policy is made at block 540. Regardless ofwhether a final insurance policy is issued at block 540, the bridginginsurance policy will be terminated. This ensures that the risk to thecompany issuing the bridging insurance policy is minimized. If a finalinsurance policy is to be issued, it is issued at block 550.

FIG. 6 shows a flow diagram of a method of processing a customer forfinancial services in a system, in accordance with an exampleembodiment. In an embodiment, a member 602 is requesting a lifeinsurance policy 604 from the insurance company 606. As discussed above,a life insurance policy 604 is just one of many financial services thatcould be offered to a customer through the systems and methods discussedhere and use of a life insurance policy 604 as an example is not meantto be limiting in any manner. The scenario discussed here will be withrespect to an interaction with an agent, or service representative, atthe life insurance company 604, though this is only meant as an example,and the systems and methods described here have equal applicability to asystem where the requestor interacts solely or in part with an automatedsystem, such as a computer server operated by the life insurance company606. In this example, the requestor is already a member of the lifeinsurance company 606, which is a member-owned insurance cooperative.

In an embodiment, the life insurance company 606 operates a call center608 to service the request of the member 602. The call center 608 is aphysical or virtual grouping of agents or service representativesavailable for dynamic interaction with the member 602, in one example.The call center 608 receives calls from members and is capable offacilitating the issuance of a bridging insurance policy and a finalinsurance policy, according to the methods and systems previouslydescribed. In addition to the call center 608, the life insurancecompany 604 operates a provider manager 610 that is in communicationwith the call center 608. The provider manager 610 is capable ofreceiving requests for information from the call center, the informationrequired for the approval of the financial service. As discussed above,acquiring the information requires the completion of one or moreexternal processes 612. These external processes may be completed by oneor more external providers 614. The provider manager 610, in oneexample, performs the function of managing the request for informationand the receipt of information related to that request. The providermanager 610 may be a software application executed on any suitablecomputer device, in one embodiment. In an alternate embodiment, theprovider manager 610 may be a physical or virtual grouping of servicerepresentatives that manage the external processes through any suitablemeans.

The member 602 calls into the call center 608 operated by the lifeinsurance company 606 and is connected with a service representative.The representative greets the member 602 and inquires as to how they canhelp the member 602 today. In this scenario, the member 602 indicatestheir desire to obtain life insurance coverage. The representativeobtains information from the member 602 concerning their situation andsome personal details. Based on this information, the representative maysuggest an amount of coverage that would be fiscally responsible basedon the needs of that particular member 602 and then inquire if themember 602 wishes to proceed further. The representative would then askquestions based on a Risk Profile analysis, the Risk Profile analysisused to determine the risk class of the member 602. The risk class maybe unobtainable in some cases where the member 602 has a high-riskoccupation, or has a medical condition. In such cases, a specificdetermination needs to be made as to the risk associated with insuringthat member 602. In such a situation, the member 602 may also beineligible for a bridging life insurance policy. The risk class is alsoused to initially determine the premium for the amount of coveragerequested. This premium may change after more information is obtained.Additionally, the service representative at the call center 608 mayquery the medical information bureau (MIB) for other information relatedto the member, or to verify the information received during the call.The MIB is a privately operated service used by companies in theinsurance industry.

Using the premium quote, the representative informs the member 602 thatthey are eligible for coverage and again inquires if the member 602wishes to proceed further. By using the information already obtained,the representative determines if the member 602 is eligible for abridging insurance policy 616. In one example, the representative mustanswer yes to the following questions in order to qualify the member 602for a bridging insurance policy 616: are they eligible for otherinsurance offered by the insurance company 606, is the coverage amountrequested below a certain amount, such as $500,000, and are they in astate where a bridging insurance policy 616 is allowable by law.Additionally, the insurance company 606 may choose to allow membersrequesting insurance coverage in excess of that certain amount, but onlyoffer a bridging insurance policy 616 up to that certain amount. Forexample, the member 602 requests $1,000,000 in coverage and they areeligible in all other ways for the bridging insurance policy 616. Therepresentative can qualify them for the bridging insurance policy 616,but only up to a certain amount, such as $500,000.

If the member 602 is eligible, the representative can communicate thatto the member 602 and tell them that they are eligible to be coveredimmediately under this program. The representative informs them of theterms of the bridging insurance policy 616 and the requirements for theprogram. In this example, the member 602 is required to pay two monthsof premiums. Additionally, the member 602 agrees to perform theirrequired processes within a certain period of time. For example, theyagree to complete and fill out all the application forms within 15 days.They are informed that failure to do so will result in the terminationof the bridging insurance policy 616. Other conditions may be placed onthe member 602 as are suitable and these are only illustrative. Afterbeing informed of the program and informed of their obligations, therepresentative asks the member 602 if they wish to take advantage of theprogram. The representative can process the 2 month premium payment overthe phone through any means, such as electronic check or credit card.Additionally, if the member 602 has a banking relationship with a bankclosely associated with the life insurance company 604, a wire transferfrom the member's 602 bank account could also be used.

The insurance company 606 notes in their systems that the member 602 ispart of a instant coverage program so that internal processes of theinsurance company 606 can be expedited. Additionally, this may mean thatforms provided to the member 602 for completion are also provided withpre-addressed and postage paid envelopes. In one example, a pre-paidFederal Express envelope is provided to the member 602.

Providing instant coverage to a member 602 is a risk to the insurancecompany 606. The insurance company 606 may require some security deviceto reduce its risk during the period of the bridging insurance policy616. However, using the member's previous relationship with theinsurance company 606 as an indicator of the risk during the period ofthe bridging insurance policy, the insurance company may require nothingmore then the commitment of the member to complete the steps required toissue a final life insurance policy 604. In other words, the insurancecompany 606 may require no security device from the member 602.

The bridging insurance policy 616 should be terminated if the member 602fails to perform what is required of them, or if at any point in theprocess it is found that the member 602 is in a risk class that is noteligible for instant coverage. Such a situation might occur if duringthe medical examination it is found that there is a pre-existing medicalcondition that significantly changes the risk class for the member 602,such as diabetes or heart disease. However, termination of instantcoverage would only occur after the member 602 is contacted and informedof the situation. In the case of failure to provide the paperworkrequired to complete the application process, this may mean that therepresentative can decide to continue the instant coverage if the member602 agrees to complete the paperwork and send it in a timely manner.

FIG. 7 shows a block diagram of a machine including instructions toperform any one or more of the methodologies described herein. A system700 includes a computer 710 connected to a network 714. The computer 710includes a processor 720, a storage device 722, an output device 724, aninput device 726, and a network interface device 728, all connected viaa bus 730. The processor 720 represents a central processing unit of anytype of architecture, such as a CISC (Complex Instruction SetComputing), RISC (Reduced Instruction Set Computing), VLIW (Very LongInstruction Word), or a hybrid architecture, although any appropriateprocessor may be used. The processor 720 executes instructions andincludes that portion of the computer 710 that controls the operation ofthe entire computer. Although not depicted in FIG. 7, the processor 720typically includes a control unit that organizes data and programstorage in memory and transfers data and other information between thevarious parts of the computer 710. The processor 720 receives input datafrom the input device 726 and the network 714, reads and stores code anddata in the storage device 722, and presents data to the output device724.

Although the computer 710 is shown to contain only a single processor720 and a single bus 730, the disclosed embodiment applies equally tocomputers that may have multiple processors, and to computers that mayhave multiple busses with some or all performing different functions indifferent ways.

The storage device 722 represents one or more mechanisms for storingdata. For example, the storage device 722 may include read only memory(ROM), random access memory (RAM), magnetic disk storage media, opticalstorage media, flash memory devices, and/or other machine-readablemedia. In other embodiments, any appropriate type of storage device maybe used. Although only one storage device 722 is shown, multiple storagedevices and multiple types of storage devices may be present. Further,although the computer 710 is drawn to contain the storage device 722, itmay be distributed across other computers, for example on a server.

The storage device 722 includes a controller 732 and data items 734. Thecontroller includes instructions capable of being executed on theprocessor 720 to carry out the functions, as previously described abovewith reference to FIGS. 1-6. In another embodiment, some or all of thefunctions are carried out via hardware in lieu of a processor-basedsystem. In one embodiment, the controller is a web browser, but in otherembodiments, the controller may be a database system, a file system, anelectronic mail system, a media manager, an image manager, or mayinclude any other functions capable of accessing data items. Of course,the storage device 722 may also contain additional software and data(not shown), which is not necessary to understanding the invention.

Although the controller 732 and the data items 734 are shown to bewithin the storage device 722 in the computer 710, some or all of themmay be distributed across other systems, for example on a server andaccessed via the network 714.

The output device 724 is that part of the computer 710 that displaysoutput to the user. The output device 724 may be a liquid crystaldisplay (LCD) well-known in the art of computer hardware. But, in otherembodiments the output device 724 may be replaced with a gas orplasma-based flat-panel display or a traditional cathode-ray tube (CRT)display. In still other embodiments, any appropriate display device maybe used. Although only one output device 724 is shown, in otherembodiments any number of output devices of different types, or of thesame type, may be present. In an embodiment, the output device 724displays a user interface.

The input device 726 may be a keyboard, mouse or other pointing device,trackball, touchpad, touch screen, keypad, microphone, voice recognitiondevice, or any other appropriate mechanism for the user to input data tothe computer 710 and manipulate the user interface previously discussed.Although only one input device 726 is shown, in another embodiment anynumber and type of input devices may be present.

The network interface device 728 provides connectivity from the computer710 to the network 714 through any suitable communications protocol. Thenetwork interface device 728 sends and receives data items from thenetwork 714.

The bus 730 may represent one or more busses, e.g., USB (UniversalSerial Bus), PCI, ISA (Industry Standard Architecture), X-Bus, EISA(Extended Industry Standard Architecture), or any other appropriate busand/or bridge (also called a bus controller).

The computer 710 may be implemented using any suitable hardware and/orsoftware, such as a personal computer or other electronic computingdevice. Portable computers, laptop or notebook computers, PDAs (PersonalDigital Assistants), pocket computers, appliances, telephones, andmainframe computers are examples of other possible configurations of thecomputer 710. For example, other peripheral devices such as audioadapters or chip programming devices, such as EPROM (ErasableProgrammable Read-Only Memory) programming devices may be used inaddition to, or in place of, the hardware already depicted.

The network 714 may be any suitable network and may support anyappropriate protocol suitable for communication to the computer 710. Inan embodiment, the network 714 may support wireless communications. Inanother embodiment, the network 714 may support hard-wiredcommunications, such as a telephone line or cable. In anotherembodiment, the network 714 may support the Ethernet IEEE (Institute ofElectrical and Electronics Engineers) 802.3x specification. In anotherembodiment, the network 714 may be the Internet and may support IP(Internet Protocol). In another embodiment, the network 714 may be alocal area network (LAN) or a wide area network (WAN). In anotherembodiment, the network 714 may be a hotspot service provider network.In another embodiment, the network 714 may be an intranet. In anotherembodiment, the network 714 may be a GPRS (General Packet Radio Service)network. In another embodiment, the network 714 may be any appropriatecellular data network or cell-based radio network technology. In anotherembodiment, the network 714 may be an IEEE 802.11 wireless network. Instill another embodiment, the network 714 may be any suitable network orcombination of networks. Although one network 714 is shown, in otherembodiments any number of networks (of the same or different types) maybe present.

The embodiments described herein may be implemented in an operatingenvironment comprising software installed on any programmable device, inhardware, or in a combination of software and hardware.

Although embodiments have been described with reference to specificexample embodiments, it will be evident that various modifications andchanges may be made to these embodiments without departing from thebroader spirit and scope of the invention. Accordingly, thespecification and drawings are to be regarded in an illustrative ratherthan a restrictive sense.

1. A financial service bridging processor-implemented method comprising:receiving, through a computing device having a processor and a storagedevice containing instructions that are executable by the processor, arequest from a customer for a final financial service, wherein approvalof the request requires completion of an external process; determiningif the customer meets eligibility requirements for a bridge financialservice, wherein the determination of whether the customer meets theeligibility requirements is based on: whether the customer is apre-existing member of an organization associated with the finalfinancial service; and whether the customer provided a commitment tocomplete steps to issue the final financial service; obtaining financialinformation on the customer's previous relationships with theorganization associated with the final financial service, if it isdetermined that the customer meets eligibility requirements for thebridge financial service; determining a coverage amount and terms of thebridge financial service based on the financial information on thecustomer's previous relationships with the organization associated withthe final financial service; issuing the bridge financial serviceaccording to the determined coverage amount and terms of the bridgefinancial service upon receiving the request and determining that thecustomer meets the eligibility requirements for the bridge financialservice using the computing device; wherein the bridge financial serviceis a non-final financial service that terminates based upon issuance ofthe final financial service; initiating the external process requiredfor the approval of the final financial service using the computingdevice; issuing the final financial service upon completion of theexternal process using the computing device; and terminating the bridgefinancial service based upon issuance of the final financial serviceusing the computing device.
 2. The method of claim 1, furthercomprising: setting up the final financial service based on the externalprocess using the computing device.
 3. The method of claim 1, whereinthe value of the bridge financial service does not exceed that of thefinancial service requested.
 4. The method of claim 1, wherein issuingthe bridge financial service includes: offering the bridge financialservice to the customer; and receiving an indication from the customerof their acceptance of the bridge financial service.
 5. The method ofclaim 1, wherein the bridge financial service is a bridge insurancepolicy, and the final financial service is a final insurance policy. 6.The method of claim 5, wherein the value of the bridge insurance policydoes not exceed that of the life insurance policy requested.
 7. Themethod of claim 5, wherein the external process includes at least one ofthe following: medical examination, blood and urine analysis, orcompletion of forms.
 8. The method of claim 7, wherein the value of thebridge insurance policy does not exceed $500,000.
 9. The method of claim5, wherein issuing the bridge insurance policy is contingent upon thepayment of two premium payments.
 10. A financial service bridgingsystem, the system comprising: a processor; and a storage devicecontaining instructions that are executable by the processor, which whenexecuted perform the following operations: receiving, from a customer, arequest for a final financial service, wherein approval of the requestrequires completion of an external process; determining if the customermeets eligibility requirements for a bridge financial service, whereinthe determination of whether the customer meets the eligibilityrequirements is based on: whether the customer is a pre-existing memberof an organization associated with the final financial service; andwhether the customer provided a commitment to complete steps to issuethe final financial service; obtaining financial information on thecustomer's previous relationships with the organization associated withthe final financial service, if it is determined that the customer meetseligibility requirements for the bridge financial service; determining acoverage amount and terms of the bridge financial service based on thefinancial information on the customer's previous relationships with theorganization associated with the final financial service; issuing thebridge financial service according to the determined coverage amount andterms of the bridge financial service upon receiving the request anddetermining that the customer meets the eligibility requirements for thebridge financial service; wherein the bridge financial service is anon-final financial service that terminates based upon issuance of thefinal financial service; initiating the external process required forthe approval of the final financial service; issuing the final financialservice upon completion of the external process; and terminating thebridge financial service based upon issuance of the final financialservice.
 11. The system of claim 10, wherein the instructions whenexecuted perform the following function: setting up the final financialservice based on the external process.
 12. The system of claim 10,wherein the value of the bridge financial service does not exceed thatof the financial service requested.
 13. The system of claim 10, whereinissuing the bridge financial service includes: offering the bridgefinancial service to the customer; and receiving an indication from thecustomer of their acceptance of the bridge financial service.
 14. Thesystem of claim 10, wherein the bridge financial service is a bridgeinsurance policy, and the final financial service is a final insurancepolicy.
 15. The system of claim 14, wherein the value of the bridgeinsurance policy does not exceed that of the life insurance policyrequested.
 16. The system of claim 14, wherein the external processincludes at least one of the following: medical examination, blood andurine analysis, or completion of forms.
 17. The system of claim 16,wherein the value of the bridge insurance policy does not exceed$500,000.
 18. The system of claim 14, wherein issuing the bridgeinsurance policy is contingent upon the payment of two premium payments.19. A computer readable medium having computer executable code tangiblyembodied thereon for processing a customer for a financial servicecontained therein, the computer executable code performing the followingoperations: receiving, from a customer, a request for a final financialservice, wherein approval of the request requires completion of anexternal process; determining if the customer meets eligibilityrequirements for a bridge financial service, wherein the determinationof whether the customer meets the eligibility requirements is based on:whether the customer is a pre-existing member of an organizationassociated with the final financial service; and whether the customerprovided a commitment to complete steps to issue the final financialservice; obtaining financial information on the customer's previousrelationships with the organization associated with the final financialservice, if it is determined that the customer meets eligibilityrequirements for the bridge financial service; determining a coverageamount and terms of the bridge financial service based on the financialinformation on the customer's previous relationships with theorganization associated with the final financial service; issuing thebridge financial service according to the determined coverage amount andterms of the bridge financial service upon receiving the request anddetermining that the customer meets the eligibility requirements for thebridge financial service; wherein the bridge financial service is anon-final financial service that terminates based upon issuance of thefinal financial service; initiating the external process required forthe approval of the final financial service; issuing the final financialservice upon completion of the external process; and terminating thebridge financial service based upon issuance of the final financialservice.
 20. The computer readable medium of claim 19, the computerexecutable code performing the following operation: setting up the finalfinancial service based on the external process.
 21. The computerreadable medium of claim 19, wherein the value of the bridge financialservice does not exceed that of the financial service requested.
 22. Thecomputer readable medium of claim 19, wherein issuing the bridgefinancial service includes: offering the bridge financial service to thecustomer; and receiving an indication from the customer of theiracceptance of the bridge financial service.
 23. The computer readablemedium of claim 19, wherein the bridge financial service is a bridgeinsurance policy, and the final financial service is a final insurancepolicy.
 24. The computer readable medium of claim 23, wherein the valueof the bridge insurance policy does not exceed that of the lifeinsurance policy requested.
 25. The computer readable medium of claim23, wherein the external process includes at least one of the following:medical examination, blood and urine analysis, or completion of forms.26. The computer readable medium of claim 25, wherein the value of thebridge insurance policy does not exceed $500,000.
 27. The computerreadable medium of claim 23, wherein issuing the bridge insurance policyis contingent upon the payment of two premium payments.